This is relied on by wundergraph.

Prevents LateContext::maybe_typeck_results() from returning data in a
nested item without a body. Consequently, LateContext::qpath_res is less
likely to ICE when called in a nested item. Would have prevented
rust-lang/rust-clippy#4545, presumably.

Actually fulfills the documented guarantees.

Add expected error

Add comment

Tweak comment wording

Fix after rebase to updated master

Fix after rebase to updated master

Distinguish mutation in normal and move closures

Tweak error message

Fix error message for nested closures

Refactor code showing mutated upvar in closure

Remove debug assert

B

 ### Overview

    This commit begins the implementation work for RFC 2945. For more
    information, see the rendered RFC [1] and tracking issue [2].

    A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
    and `Thiscall` variants, marking whether unwinding across FFI
    boundaries is acceptable. The cases where each of these variants'
    `unwind` member is true correspond with the `C-unwind`,
    `system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings
    introduced in RFC 2945 [3].

 ### Feature Gate and Unstable Book

    This commit adds a `c_unwind` feature gate for the new ABI strings.
    Tests for this feature gate are included in `src/test/ui/c-unwind/`,
    which ensure that this feature gate works correctly for each of the
    new ABIs.

    A new language features entry in the unstable book is added as well.

 ### Further Work To Be Done

    This commit does not proceed to implement the new unwinding ABIs,
    and is intentionally scoped specifically to *defining* the ABIs and
    their feature flag.

 ### One Note on Test Churn

    This will lead to some test churn, in re-blessing hash tests, as the
    deleted comment in `src/librustc_target/spec/abi.rs` mentioned,
    because we can no longer guarantee the ordering of the `Abi`
    variants.

    While this is a downside, this decision was made bearing in mind
    that RFC 2945 states the following, in the "Other `unwind` Strings"
    section [3]:

    >  More unwind variants of existing ABI strings may be introduced,
    >  with the same semantics, without an additional RFC.

    Adding a new variant for each of these cases, rather than specifying
    a payload for a given ABI, would quickly become untenable, and make
    working with the `Abi` enum prone to mistakes.

    This approach encodes the unwinding information *into* a given ABI,
    to account for the future possibility of other `-unwind` ABI
    strings.

 ### Footnotes

[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: rust-lang#74990
[3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings

 ### Changes

    This commit implements unwind ABI's, specified in RFC 2945.

    We adjust the `rustc_middle::ty::layout::fn_can_unwind` function,
    used to compute whether or not a `FnAbi` object represents a
    function that should be able to unwind when `panic=unwind` is in
    use.

    Changes are also made to
    `rustc_mir_build::build::should_abort_on_panic` so that the
    function ABI is used to determind whether it should abort, assuming
    that the `panic=unwind` strategy is being used, and no explicit
    unwind attribute was provided.

 ### Tests

    Unit tests, checking that the behavior is correct for `C-unwind`,
    `stdcall-unwind`, `system-unwind`, and `thiscall-unwind`, are
    included. These alternative `unwind` ABI strings are specified in
    RFC 2945, in the "_Other `unwind` ABI strings_" section.

    Additionally, a test case is included to assert that the LLVM IR
    generated for an external function defined with the `C-unwind` ABI
    will be appropriately labeled with the `nounwind` LLVM attribute
    when the `panic=abort` compilation flag is used.

 ### Add debug assertion to check `AbiDatas` ordering

    This makes a small alteration to `Abi::index`, so that we include a
    debug assertion to check that the index we are returning corresponds
    with the same abi in our data array.

    This will help prevent ordering bugs in the future, which can
    manifest in rather strange errors.

 ### Using exhaustive ABI matches

    This slightly modifies the changes from our previous commits,
    favoring exhaustive matches in place of `_ => ...` fall-through
    arms.

    This should help with maintenance in the future, when additional
    ABI's are added, or when existing ABI's are modified.

Co-authored-by: Niko Matsakis <[email protected]>

 ### Changes

    This commit addresses some test failures that now occur in the
    following two tests:

        * no_std-alloc-error-handler-custom.rs
        * no_std-alloc-error-handler-default.rs

    Each test now defines a `rust_eh_personality` extern function, in
    the same manner as shown in the "Writing an executable without
    stdlib" section of the `lang_items` documentation here:
    https://doc.rust-lang.org/unstable-book/language-features/lang-items.html#writing-an-executable-without-stdlib

    Without this change, these tests would fail to compile due to a
    linking error explaining that there was an "undefined reference
    to `rust_eh_personality'."

 ### Changes

    This commit introduces some new fixtures to the `run-make-fulldeps`
    test suite.

        * c-unwind-abi-hello-world: A simple "happy path" fixture. This
          involves calling from Rust, into C, and back into a Rust
          `C-unwind` function.

        * c-unwind-abi-catch-panic: Exercise unwinding a panic. This
          reuses much of the same code, but instead catches a panic and
          downcasts it into an integer.

        * c-unwind-abi-catch-lib-panic: This is similar to the previous
         `*catch-panic` test, however in this case the Rust code that
         panics resides in a separate crate.

 ### Changes

    This is a small commit, updating the `c-unwind` page in the unstable
    book to list _all_ of the other ABI strings that are introduced by
    this feature gate.

    Now, all of the ABI's specified by RFC 2945 are shown.

Co-authored-by: Amanieu d'Antras <[email protected]>

This commit addresses a tidy error that currently occurs on this branch:

```
tidy error:
    following path contains more than 1458 entries,
    you should move the test to some relevant
    subdirectory (current: 1459): /checkout/src/test/ui
```

Co-authored-by: bjorn3 <[email protected]>

The angle brackets were not rendered, so code like this:

    some_func: for<'a> fn(val: &'a i32) -> i32

would be rendered as:

    some_func: fn'a(val: &'a i32) -> i32

However, rendering with angle brackets is still invalid syntax:

    some_func: fn<'a>(val: &'a i32) -> i32

so now it renders correctly as:

    some_func: for<'a> fn(val: &'a i32) -> i32

-----

However, note that this code:

    some_trait: dyn for<'a> Trait<'a>

will still render as:

    some_trait: dyn Trait<'a>

which is not invalid syntax, but is still unclear. Unfortunately I think
it's hard to fix that case because there isn't enough information in the
`rustdoc::clean::Type` that this code operates on. Perhaps that case can
be fixed in a later PR.

cc rust-lang#79813

This PR adds an allow-by-default future-compatibility lint
`SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a
macro body is ignored due to the macro being used in expression
position:

```rust
macro_rules! foo {
    () => {
        true; // WARN
    }
}

fn main() {
    let val = match true {
        true => false,
        _ => foo!()
    };
}
```

The lint takes its level from the macro call site, and
can be allowed for a particular macro by adding
`#[allow(semicolon_in_expressions_from_macros)]`.

The lint is set to warn for all internal rustc crates (when being built
by a stage1 compiler). After the next beta bump, we can enable
the lint for the bootstrap compiler as well.

…945-c-unwind-abi, r=Amanieu

Implement RFC 2945: "C-unwind" ABI

## Implement RFC 2945: "C-unwind" ABI

This branch implements [RFC 2945]. The tracking issue for this RFC is rust-lang#74990.

The feature gate for the issue is `#![feature(c_unwind)]`.

This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19.

### Changes

Further details will be provided in commit messages, but a high-level overview
of the changes follows:

* A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI boundaries is
acceptable. The cases where each of these variants' `unwind` member is true
correspond with the `C-unwind`, `system-unwind`, `stdcall-unwind`, and
`thiscall-unwind` ABI strings introduced in RFC 2945 [3].

* This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`, which
ensure that this feature gate works correctly for each of the new ABIs.
A new language features entry in the unstable book is added as well.

* We adjust the `rustc_middle::ty::layout::fn_can_unwind` function,
used to compute whether or not a `FnAbi` object represents a function that
should be able to unwind when `panic=unwind` is in use.

* Changes are also made to
`rustc_mir_build::build::should_abort_on_panic` so that the function ABI is
used to determind whether it should abort, assuming that the `panic=unwind`
strategy is being used, and no explicit unwind attribute was provided.

[RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md

…micolon, r=petrochenkov

Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint

cc rust-lang#79813

This PR adds an allow-by-default future-compatibility lint
`SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a
macro body is ignored due to the macro being used in expression
position:

```rust
macro_rules! foo {
    () => {
        true; // WARN
    }
}

fn main() {
    let val = match true {
        true => false,
        _ => foo!()
    };
}
```

The lint takes its level from the macro call site, and
can be allowed for a particular macro by adding
`#[allow(macro_trailing_semicolon)]`.

The lint is set to warn for all internal rustc crates (when being built
by a stage1 compiler). After the next beta bump, we can enable
the lint for the bootstrap compiler as well.

…llaumeGomez,jyn514

rustdoc: Render HRTB correctly for bare functions

The angle brackets were not rendered, so code like this:

    some_func: for<'a> fn(val: &'a i32) -> i32

would be rendered as:

    some_func: fn'a(val: &'a i32) -> i32

However, rendering with angle brackets is still invalid syntax:

    some_func: fn<'a>(val: &'a i32) -> i32

so now it renders correctly as:

    some_func: for<'a> fn(val: &'a i32) -> i32

-----

However, note that this code:

    some_trait: dyn for<'a> Trait<'a>

will still render as:

    some_trait: dyn Trait<'a>

which is not invalid syntax, but is still unclear. Unfortunately I think
it's hard to fix that case because there isn't enough information in the
`rustdoc::clean::Type` that this code operates on. Perhaps that case can
be fixed in a later PR.

r? `@jyn514`

Use -target when linking binaries for Mac Catalyst

When running `rustc` with `-target x86_64-apple-ios-macabi`, the linker
eventually gets run with `-arch x86_64`, because the linker back end splits the
LLVM target triple and uses the first token as the target architecture. However,
this does not work for the Mac Catalyst ABI, which is a separate target from
Darwin.

Specifying the full target triple with `-target` allows Mac Catalyst binaries to
link and run.

closes rust-lang#80202

…=nikomatsakis

Make hitting the recursion limit in projection non-fatal

This change was originally made in rust-lang#80246 to avoid future (effectively) infinite loop bugs in projections,
but wundergraph relies on rustc recovering here.

cc rust-lang#80953

r? `@nikomatsakis`

…1011

Point to span of upvar making closure FnMut

For rust-lang#80313.

Improve safety of `LateContext::qpath_res`

This is my first rustc code change, inspired by hacking on clippy!

The first change is to clear cached `TypeckResults` from `LateContext` when visiting a nested item. I took a hint from [here](https://github.com/rust-lang/rust/blob/5e91c4ecc09312d8b63d250a432b0f3ef83f1df7/compiler/rustc_privacy/src/lib.rs#L1300).

Clippy has a `qpath_res` util function to avoid a possible ICE in `LateContext::qpath_res`. But the docs of `LateContext::qpath_res` promise no ICE. So this updates the `LateContext` method to keep its promises, and removes the util function.

Related: rust-lang/rust-clippy#4545

CC ```````````@eddyb``````````` since you've done related work
CC ```````````@flip1995``````````` FYI

…=Mark-Simulacrum

BTreeMap: correct node size test case for choices of B

r? ```@Mark-Simulacrum```